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(54) Management system architecture & design method to support reuse 



(57) A management base of a communications net- 
work manager is constructed using object oriented 
techniques. A network comprises a plurality of physical 
resources in the form of components and assemblies of 
components, which are distributed across the network. 
A management system for the network is constructed in 
an evolutionary manner by representing an overall func- 
tionality of the network by an application model (1402) 
in which each function of the network is nxxieled inde- 
pendently of its Implementation, decomposing the appli- 
cation model into an implementation modeH (1404) in 



which every function represented in tiie application 
nrxxlel is represented in the inplementation nrxxJel. rep- 
resenting the application nrxxjel as a plurality of objects 
(1408). representing the implementation model as 
another plurality of objects (1411). connecting the 
objects of the applicatbn nrxxiel and implementation 
nxxiel together to obtain a combined object nrxxlel, and 
constructing a management base according to the com- 
bined object model. 
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Description 

neld of the tnvention 

5 [0001 ] The present invention relates to the management of communications networks. 
Background to the Invention 

[0002] Conventional communications networks, for example parlicularty broadband communk:ations networks, are a 
10 result of continuous evolution of technologies over a number of past decades. A conventional communications network 
comprises a plurality of network elements, such as switches, cross-connects, repeaters and terminala Persons design- 
ing new communications networks, or modrfk^ations to existing communications networks have a large selection of 
hardware based equipment items available from different manufacturers, different equipment having different perfomn- 
ances, and operating different transmissfon protocols according to cfifferent standards. Even the network equipment 
75 products availat)le from a single nrianufacturer can vary considerably in functionality, capability and nrxxie of operation 
due to the fiistoncal development of the products, and due to takeovers, mergers and alliances between different man- 
ufacturers within the telecommunications industry. There exists a large inventory of such available legacy** equipment, 
both as products currently available from manufacturers, and as existing items of network equipment currently installed 
and In use in communications networks. On the other hand, there exists a considerable number of standards bodies 
20 and alliances of manufacturers, concerned with steering the evolution of new communications technologies and proto- 
cols with a view to standardization arxi interoperability of equipment from different manufocturers. Many of the cun'ent 
standards and evolving technologies will form the legacy equpment and systems of tiie future, thereby adding to the 
volume of "legacy** equipment in use. 

[0003] Modem broadband communications networks are required to carry an inaeasing volume of communications 
25 data traff k;, having a nnxture of traffic characteristics driven by a variety of applications. Such applications include vkieo 
on demand, voice communication, arxi corrputer to computer data transfer. Operators and users of networks need to 
be able to manage their network resources to make the nrx>st cost effective use of communications networks, arxi to 
. provkie adequate servrces to their customers. Mar^gement of a network is involves management of operations, admin- 
isfration, maintenance, and provisioning of network resources (OAMP). Briefly, these elements involve the following: 

30 

• Operations involves the day-to-day arvj often mInute-to-minute care and feeding of the communications network in 
order to ensure tfiat it is fulfilling its designed purpose. Examples of operations include monitoring of the network 
by watching for faults and invoking corrective commands and/or maintenance actions to repair them, comparing 
measured network performance against objectives and taking corrective action arxi/br invoking mairrtenance. Tak- 

35 ing corrective action invoh^es operators issuing controls to correct a fault or performance problem or to resolve a 
customer complaint 

Admirtistration involves a set of activities Involved witti designing the network, processing orders, assigning 
addresses, tracking usage, and billing users of the network. 

40 

Mairrtenance involves circumstances that arise when a network does not work as planned, or it is necessary to 
diagnose and repair system faults. 

• Prcvisfoning involves installing equipment, setting parameters, verifying that a service is operational arxi de-instal- 
45 lation of eqiipment or services. 

[0004] Conventionally, such n^woric managenf>ent may be achieved through a network controller apparatus. As illus- 
trated schematically in Rg. 1 herein, a conventbnal communications network comprises a plurality of heterogeneous 
networi^ elements NE, confrolled and operated by one or mae networi< controllers NC. The network elements may be 

50 of different manufacturers*, and having different capabilities and protocols. A network controller NC typically comprises 
a workstation capable of accessing an operation, administration and management (0AM) channel comnunicating with 
each of the network elements. The network confroller receives and sends messages over the operation and manage- 
ment channel in the form of confrol signals in accordance witii standard and/or proprietary protocols. Exanples of 
widely used protocols include the simple network management protocol (SNMP) whk;h is defined in EFTF Standards. 

55 Another standard networit management protocol is the krtown common management information protocol (CMIP) of tiie 
Open System Interconnect (OSI) Committee of the International Telecommunications Union (UU-T). Otfier network 
management protocols in use include TL1 and a variety of proprietary management protocols. Currentiy, the two pre- 
vailing protocols used to convey management information in communications systems are SNMP and CMIP. There is 
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general a^eement that SNMP and its suocessa SNMP v2 are nrx>re suitable for customer premises equipment and pri- 
vate networks, whilst the common management information protocol, and the associated common management infor- 
mation service elements (CMISE) are more appropriate for carrier interconnection. For some devices, such as early 
asynchronous transfer mode (AT^ switches, it is simpler and easier to achieve interoperakMlity with SNMP than it is with 
CMIP 

[0005] Althou^^ SNMP was developed with the intention of later intercepting the International Standard Organization 
Standards such as CMIP. there are fundanrfenta! differences between the SNMP and CMIP protocols which have tradi- 
tionally inhibited inter-working of the two protocols. Differences t>etween the SNMP arxJ CMIP protocols are illustrated 
in tabUe 1 herein. 

Table 1 



CMIP (paradigm - object SNMP (paradigm - relational) 
oriented) 

Management information Management information 



• Complex object classes with 
attributes, events and actions 



• Separate hierarchies for 
registration (naming), 
contsunment and inheritance 



• Identification of instances 
based on containment plus 
distinguished attributes 



• Simple object types (simple 
variables without attributes, 
plus tables of simple variables) 

No actions or events (SNMP 
traps are not assodated with 
objects 



• A single hierarchy which is 
used for both naming and 
containment No inheritance 



• Identification of instances 
based on position in hierarchy 
plus, for table entries, a simple 
index value 



[0006] Several attempts have been made to align the SNMP and CMIP protocols and models, hlcwever. many of 
these approaches are flawed. Such approaches include: 

• CMOT {Abbreviation of CMIP flver ICP/IP) 

The internet community have proposed how to use the CMIP protocol to manage transmission and control pro- 
tocol/internet protocol fTCP/IP). CMOT ^Is because it requires significant changes to internet equipment. CMOT 
has survived only as a definition of an altemative transport layer protocol for CMIP. 

IIMC (abbreviation of ISQ/CCITT internet Management Coexistence) 

The Network Management Forum (NMF) has endorsed a scheme for translation between CMIP and SNMP 
management information bases (MIBS). This approach is undesirable because it merely provides a syntactic trans- 
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lation between SNMP and CMIP MIB formats. 

[0007] In the Network Management Forum (NMF) approach, there is proposed a Troxy mechanism which translates 
between functionally equivalent service, protocol and management information base differences. SNMP object types 

5 are mapped to "equivalent" ISO/CCm object classes and attrixjtes as illustrated schematically in Rg. 2 herein. No 
attempt is made to modify the basic shape of the SNMP management information base, so classes normally seen in 
GDMO management information bases such as the connection object from ITU-T Recommendation G.803 do not 
appear. The structure of the management information base and the access mechanisms having protocol specific views 
of the management information base are cleanly separated in the NMF model. The NMF concept enables a network- 

10 wide model to be constructed which is independent of the various "views" upon It Neither of the above approaches 
addresses the key issue of how to manage systems composed of multiple heterogeneous network elements. 
[0008] Independent proposals made within the International Community for development of management models for 
communications networks include. 

15 • IBM (International Business Machines) have proposed how to organize a single management information base 
such that it can be independentiy accessed by either CMIP or SNMP protocols. 

• The network management forum has specified a protocol independent management infomnation base format and 
is encouraging the development of commercial tools to provide protocol specify access. 

20 

The ATM Forum has used a protocol irxJeperKierTt notation to nxxlel requirements for ATM network and element 
management. 

[0009] Referring to Fig. 3 herein in the IBM scheme, a protocol independent nnanagement information base 300 is 
25 provided with a generic interface 301 . The generic interface 301 is accessed via an SNMP protocol object 302, and/or 
CMIP protocol object 303, conprising respectively an SNMP interface 304 and a CMIP interface 305. 
[0010] However, despite these proposals, current management systems for telecommunications networks are con- 
structed on an ad hoc t>asis. Once system designers have designed a new communications network, or a nxxlif Nation 
to an existing communications network, the network manager system is created, reflecting the structure, connections 
30 and services present in the new network. The conventional management system comprises a management information 
base, in the form of a data storage devrce storing electronic data signals descn'bing each of the network elements of the 
network, their interconnections, and the services and protocols supported by those network elements. 
[001 1 ] Problems which occur with ttie conventional approach network management indude: 

35 • Each time a new network is designed, a new custonrHnade managemerrt infbrn^tion base needs to be created. 

Conventional methods of managemerrt information base creation involve considering the design of a management 
information base as a whole whenever a new type of network element is aeated, or whenever a new network ele- 
ment is added to an existing network. For example when a new network element is added to an existing network. 
40 changes to the data stored in the management information t>ase nrtust be added to rdlect the addition of the new 
network element. In conventional management information bases, ttie changes to the management information 
t>ase required on addition of a new network element are difficult to contain due to the cross-references between 
data items stored in the MIB. 

45 • Conventional management systems are not easily scaleat)le. As the complexity of the network increases, so does 
the complexity of the management information base required. For networks having more than a few hundred 
nodes, a plurality of network management systenns are used. This results in architectural conrplexity of manage- 
ment systems in order to compensate for lack of scaleability in the inherent design of the management system. 

50 Summary of the Invention 

[001 2] One object of the present invention is provide a process which enables faster construction of a network man- 
agement system for a communications networK by supporting re-usability of network management system construc- 
tions. 

55 [001 3] Another object of the present invention is to provide a process for constructing a network management system 
in which containment of changes to the management system is achieved, on addition of new hardware and software 
item types to a communications network. 

[0014] Another object of the present invention is to introduce readily scaleable architectures into a network manage- 
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merrt system with a view to reducing time to market. 

[001 51 A further object of the present Iriyention is to provide a way of constaicting a network managemerrt system 
which is adaptable to being distrOxited across a communications network In the specific methods and embodiments of 
the proposed approach herein. 
5 [001 6] a network is considered to comprise a plurality of components, a component being a replaceable unit of man- 
ufacture which lends itself to duplication throughout a network and which is manageable by a disaete unit of manage- 
ment functionality. A plurality of components are assembled, or co-operate with each other to form a composite of 
components, which provides functionality based on the functionality of Individual components comprising the compos- 
ites. 

10 [001 7] By providing a network management apparatus which is structured in a way which reflects the assemt>lies of 
components, composites and systems of a network independently of their functbnality. there may be created a man- 
agement platform which supports management control of internal features of network systems and conposites of net- 
work conrponents in a graded manner, in which management access can be achieved throughout a plurality of levels of 
a network. 

75 [001 8] According to a first aspect of the present invention, there is provided a method of constructing a management 
base of a communications network, sakJ communications network comprising: 

a plurality of components, each component comprising a unit of manufacture providing a functionality witiiin said 
network, and which is capable of k>eing managed individually as a disaete entity; 

20 

said plurality of components arranged into a plurality of assemblies of components, each said assembly arranged 
to co-operate with other said assemblies, and each said assembly capable of being managed as a whole; 

said method comprising the steps of: 

25 

representing an overall functionality of saki network by an application model, in whk:h each said function of said 
network is modeled independentiy of its implementation within said network; 

decomposing saki applk^ation model into an implementation model, in whk;h every function represented by said 
30 application model is represented in said implementation model; 

representing said applk:ation model as a f irst plurality of objects; 

representing said implementation vnode\ as a second plurality of objects; 

35 

connecting said first plurality of objects with saki second plurality of objects to obtain a combined object nxxiel; and 
constructing said management t>ase in accordance witii saki combined object nxxiel. 

40 [001 9] A management system is constructed from a plurality of managed objects according to a model which reflects 
both the pure functionality of composites, at an application level and the implementation of those functions by the com- 
posites and components, at an Inplementation level. Functbnality at tiie applbation levels and implementation levels 
is represented in the arrangement of managed objects comprising the network management system, which are sepa- 
rated into application level models and implementation level models, which are used to construct a management infbr- 

45 mation base. 

[0020] This may allow separation of a network application functionality, for example a system, which is being managed 
from management of an item of equipment such as a component or a corrposite. 

[0021 ] Preferably, said step of representing said application model as a f ir^ plurality of objects comprises modeling 
a connectivity layering between irxiivkiual nxxieled functions within saki application model. 
50 [0022] Preferably, saki step of representing saki implementation model as a second plurality of objects comprises 
modeling connectivities t>etween assemblies of components at a first layer and assemblies of components at a secorxi 
layer. 

[0023] Preferably, the nYethod comprises the step of optimizing said application dass model by kientifying symmetri- 
cal portions of saki applicatbn class model; and fokiing saki symmetrical portions to obtain a foUed application dass 
55 model. 

[0024] Preferably saki method comprises the step of optimizing saki implementation dass model by kientifying sym- 
metrk;al portions of saki implementation dass model; and fokiing saki symmetrical portions of said implementation 
dass model to obtain a folded implementation class model. 
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[0025] Suitably, individual portions of said implementation model representing duplicated components or assemblies 
of components are re-used wrthin said Implementation model. 

[0026] Suitably, Individual elements of said application nrxxiel representing a diplicated said component, or a dupli- 
cated said assembly of components is re-used witfiin said application nrxxjel. 

5 

Brief Pesciiption of the Drawings 

[0027] For a better understanding of tfie invention and to show how the same may be carried into effect, there will new 
be deserved by way of example only, specific embodiments, methods and processes according to the present Invention 
10 with reference to the accompanying drawings in which: 

Rg. 4 illustrates an example of a communications network comprising a plurality of node elements linked together 
by a plurality of links, and illustrating different levels of management of tiie network; 

IS Fig. 5 illustrates a n^work controller apparatus comprising network management system according to a specific 
embodiment of the present invention; 

Rg. 6 illustrates an internal architecture of a network controller comprising a management system having an appli- 
cation controller arxi an implementation controller; 

20 

Rg. 7 illustrates a replaceat)le component of a communications network, together with a component controller for 
controlling functionality of the component; 

Rg. 8 illustrates a composite assembly of components, comprising a network element together with a composition 
25 of conrponent controllers for implementing control of tiie conrponents. and a furwrtion controller representing func- 
tionality of the network element; 

Rg. 9 illustrates an example of internal structure of a function controller and an element controller of tiie network 
controller of Rg. 5; 

30 

Rg. 10 illustrates a sub-function controller of the function controller of Rg.9; 
Rg. 1 1 illustrates a sub-component controller of the composite controller of Rg. 9; 
35 Rg. 1 2 illustrates an architectural structure of the network management system; 

Rg. 13 illustrates a general mettiod of construction of a network management system; 

Rg. 1 4 illustrates in overview a method for constructing an application level and an implementation level of the man- 
40 agement system; 

Rg. 15 illustrates a "t)lack box" application view of a composite according to the method of Rg. 14; 

Rg. 16 illustrates an implementation view internal layout of a composite according to the method of Rg. 14; 

45 

Rg. 17 illustrates a layered connection representation of a composite according to the method of Rg. 14; 

Rg. 18 illustrates an application dass representatbn of a composite according to the method of Fig. 14; 

50 Rg. 19 illustrates a layered implementation representation of a composite according to the method of Rg. 14; 

Rg. 20 illustrates an implementation dass representation of a composite according to the method of Fig. 14; 

Rg. 21 illustrates a fokied irrplementation dass representation for constructing a composite controller of a compos- 
55 Ite, according to tiie method of Rg. 1 3; 

Rg. 22 illustrates a combined application dass nrxxiel and irrplementation dass model representation for connect- 
ing a function controller and a composite controller of a network management system, according to the nrtethod of 
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Fig. 9; 

Fig. 23 iltustrates a relationship between application models and implementation nxxiels at different levels of sys- 
tem management; 

5 

Fig. 24 Illustrates a "t)lack box" view of an E1 1/0 cross-connect ever ATM application; 

Fig. 25 Illustrates a block diagram architecture for an E1 1/0 cross-connect ever ATM system architecture; 

10 Fig. 26 illustrates schematically an Implementation nrKxjel representation of the El 1/0 cross-connect ever ATM as 
a set of connected components; 

Fig. 27 illustrates a simplified block diagram of the El 1/0 cross-connect architecture; 
15 Fig. 28 illustrates a layered implementation representation of the El 1/0 cross-connect over ATM system; 
Fig. 29 illustrates an Implementation class model of the El 1/0 cross-connect ever ATM; 
Fig. 30 illustrates an optimized, fbkled imptemerrtation dass mo6e\ of the El 1/0 cross-connect; 

20 

Fig. 31 illustrates a layered implementation dass nrxxlel of an E1-ATM adapter composite of the El 1A) cross-con- 
nect; 

Fig. 32 illustrates a fokjed Inrplementatfon dass wodeA of the El -ATM adapter composite of Rg. 31 ; 

25 

Fig. 33 illustrates a mapping between an application dass model and an implementation dass model of the El 1/0 
cross-connect ever ATM; 

Fig. 34 illustrates in general overview stages iri developing an application model tfirough an architecture model to 
30 an implementation model for a 1/0 cross-connect; 

Fig. 35 illustrates a "black box" view of an ATM transit exchange application; 

Fig. 36 illustrates a dock diagram architecture for the transit exchange of Fig. 35; 

35 

Fig. 37 illustrates a block diagram for an implementation of the transit exchange as a set of connected componerrts. 
some of which eg DSO - ATM adaptor) are reused from the El 1A) cross connect system; 

Fig. 38 illustrates an intermediate step between a t3lack box view and an application dass model for the ATM transit 
40 exchange; 

Fig. 39 illustrates a simplified application dass nrxxlel, for a function controller for controlling an ATM transit 
exchange apparatus; 

45 Fig. 40 illustrates an implementation dass model of the vok;e over ATM transit exchange; 

Fig. 41 illustrates a combination of a portion of an applicatfon class model and a portion of an implementatfon dass 
nrxxJel for the ATM transit exchange witii mappings between managed object dasses in the two models; 

50 Fig. 42 illustrates an intermediate step In the development of an implementation dass nxxJel for a call processing 
nfxxlule of the ATM transit exchange; 

Fig. 43 illustrates an inplementation class model of a processor module of the ATM transit exchange, comprising 
an MTP-3 processor nmlule and an ISUP/CC processor module; 

55 

Fig. 44 illustrates an implementation class nxxiel of a generic spared processor module of tiie ATM transit 
exchange; 
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Rg. 45 illustrates a block diagram architecture lor an E1 -ATM adapter; 

Rg. 46 illustrates an intermediate step between the block diagram of Rg. 45 and an implementation dass model off 
the E1 -ATM adapter; 

5 

Rg. 47 illustrates an implementation dass model of an El protection module portion off the E1-ATM adapter Imple- 
mentation model of Rg. 45; 

Rg. 48 illustrates an implementation dass nxxjel fragment off an ATM transit exchange, showing hofw a signaling 
70 link is switched internally through the El ATM adaptor and frame processor components to its termination within 
the MTP-3 processor component; 

Rg. 49 illustrates a combined dass model inducfing application class model and inplementation dass model por- 
tions for a sectk>n of an ATM transit exchange, induding an E1 -ATM adaptor implementation dass model, a frame 
15 processor implementation dass model and an MTP-3 processor implementation dass model connected with a sig- 
naling cross-corn ect between signaling link connection termination point elements, one of which is mapped to an 
application class model within the combined dass model; 

Rg. 50 illustrates a common object model illustrating a management unit for an item of common equipment which 
20 can be customized to perform a specific functfonality; 

Rg. 51 illustrates steps for constructing a management system for a communications network having pre-defined 
components and composites; 

25 Rg. 52 illustrates a metfKxJ of constructing a set of objects to create system controllers, composite controllers arxi 
component controllers; and 

Rg. 53 illustrates steps for variation of a method of constructing a management system for a communications net- 
work. 

30 

Detailed Description of the Best Mode for Carry ing Out the Invention 

[0028] There will now be described by way of exairple the best mode contemplated by the inventors for canying out 
the invention. In the fdfowing description numerous specific details are set forth in order to provide a thorough urxler- 
35 Standing of the present invention. It will be apparent however, to one skilled in the art. that the present invention may be 
practiced without using these specifk; details. In other instances, well known methods and structures have not been 
desCTik)ed in detail so as not to unnecessarily ot>scure the present invention. 

[0029] Referring to Rg. 4 herein, there is shown an example off a conununications network comprising a plurality of 
nodes 400, and a plurality of links 401 . the communications network b&r\Q managed by a network management system 

40 comprising one or a plurality of network controllers 402. Whereas in the conventional network shown previously in Rg. 
1 herein, network elements NE whk;h occupy nodes, conrprise monolithic devices which are heterogenous from node 
to node, which may t>e off diffferent proprietary manufacture and which are separately managed accordirigly by a plurality 
of separate management systems, in the network of Rg. 4 herein, nodes are occif}ied by a plurality of components 
whteh are capable of t)eing replicated from node to node and which support furxrtions which may t>e cGstrfouted across 

45 the network in their implementation. Composite assemblies of components are created, which provide composite func- 
tionality provided by a plurality off individual components, and from the composites and components are created com- 
plete systems witiiin the network, which provide system functionality within the network. Examples off such systems 
include GSM and ISDN functions realized through distributed network dements. 

[0030] The network is managed at diffferent levels of management At a fowest level off management termed a oom- 
50 ponent level, components of equipment are managed. In this specifk;ation tiie term "oomponenT is used to represent a 
replaceable unit of manufacture which lends itself to duplication throughout a network and which is manageat)le by a 
discrete unit of management ffunctionality. A component comprises a lowest level of managed hardware or software 
whrch is replaceat)le as a unit or which is reusak)le as a unit across diffferent areas off the network, providing a reusable 
functionality within the network. A component may comprise for example a line card in a switch devk;e. a port card, or 
55 a signal processing card. The component may typically comprise a replaceable card which slots into a backplane of an 
equipment rack module which prcvkles power supply arid means for comnruinicating with other components. A compo- 
nent may comprise a unit off software for contrdling one or a plurality off general purpose processor cards to perform a 
specrffic function witiiin the network. Another example off a component may comprise a card performing a E1-DS0 mul- 
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tiplexor function. Another example of a component may include a passive link device, eg a fiber cable. A component, 
particularly a hardware component, may generally reside at a single node, but where the component comprises a unit 
of programming, the component may reside at a single node or be distrbuted across a plurality of nodes. The compo- 
nents each comprise a plurality of sutHX>mponents such as processor chips, buffer chips, minor hardware items or 
cat)les; however by themselves such sub-componenis do not provide reusable modules in a network but are used within 
a re-usable component. 

[0031 ] At a composite management level, assemblies of components which are connected together to provide com- 
posite functionalrty are managed. In this specification, the term "composite" is used to represent an assembly of com- 
ponents which are arranged to co-operate with each other to provide a composite functionality which utilizes a plurality 
of functions provided by a plurality of components, and which are managed as a whole. An example of a composite may 
include a node device such as a switch or aoss-connect. 

[0032] At a system management level, a plurality of composites and/or components interacting wrtii each other to pro- 
vide a network system functionality are managed. In this specification the term "system" is used to represent an assem- 
bly of composites and/or components which co-operate together to perform a highest level of function which is 
managed as a whole within the network. A system forms a highest level of composite. A system may comprise two or 
more conposites or components whk:h operate to provide a self contained function, eg a service, within a network. 
Managed systems may be centralized at one node or may t>e distributed across the network. In general, composites 
and systems may be distributed across a plurality of nodes of the network, or may reside at a single node. The network 
management system may be centralized at one network controller apparatus 402, or may be distributed across a plu- 
rality of network controllers or de/ices. or even components, in which latter case the management system itself is man- 
aged as a special type of system composite. 

[0033] A cfifference between a component and a composite in terms of hardware is illi^lrated by the following exam- 
ple: whereas a replaceat>le card device having specific functionality, eg a port card, which is managed as a whole com- 
prises a component, on the other hand a device which is capat>le of carrying out a plurality of different functions, eg a 
general purpose processor card running a plurality of software packages, each software package being managed sep- 
arately wouki be an example of a composite, where each software package a component, being replaceable and 
reusat)le over different processors. 

[0034] Refferring to Rg. 5 herein, there is shown schematically a network nnanagement base for managing a plurality 
of interconnected conponents. composites and systems of a communications network. The plurality of components 
typically comprise a multitude of heterogeneous hardware based equipment itenns. wfv'ch may be of different proprie- 
tary manufacture, different specification and differing functionality. Indivklual componerrts may be replicated across the 
network as part of the different conposites and individual composites may be replicated across the network as different 
systems. The network management t>ase comprises one or a plurality of network controller apparatus 402 each having: 
a processor 500 with associated memory 501 ; a plurality of commmications ports 502 for communicating with the com- 
ponents, composites and systems; a data storage device 503. for exanple a hard disc of relatively high capacity eg 5 
Gigabits; a graphical user interface 504 comprising one or plurality of video monitors, a k0ytx>ard for manual data entry, 
one or mae data enby ports, eg floppy disc drive. CD ROM drive, and a pointing devk;e. eg a nxHJse or trackt)all devk:e; 
a plurality of component controllers 505 for providing management control signals to control management of indivkiual 
conponents. sakJ conponent controllers being arranged into a plurality of conrposite controllers 506 for provkiing man- 
agement control signals to control management of composites of conponents, and saki plurality of component control- 
lers and/or conposite controllers arranged into one or more system controllers 507 for provkfing management control 
signals to one or nx>re corresporxiing respective systems of the network. 

[0035] Herein, the term "corrponent controller" is used to represent a unit of manufacture of management functionalrty 
in a nr^agement apparatus, which is capable of implementing management functions of a component by controlling 
that component, either directly, or by interfacing with an interfece or agent of the conponent. 
[0036] Herein, the term "conrposite controller" is used to represent a unit of manufacture of managenient fi^ctionality 
in a management apparatus which is capable of inptementing management functions of a composite of components 
by controlling that composite. 

[0037] Herein, the term "system controller is used to represent a unit of manufacture of management apparatus 
which is capable of implementing management functions of a system. 

[0038] The management base may be used by a human operator to manage a flow of communications traffic data 
over the networK and for performing other operation, administration and maintenance (0AM) functions including the fol- 
lowing: 

• fault management 
performance management 

• configuration management 

• accounting management 
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security management 

[0039] In order to perform management functions, the network controller stores, in the data storage medium 503, data 
describing the 0AM functions which the network can perform, as well as data descrft>ing the structure of the network. 
5 Examples of functiorYS may include basic transport functions eg cross-connect functions, frame processing etc, as well 
as higher le\^el functions, such as service functions. 

[0040] The collection of system controllers, composite controllers and component controllers provide an information 
base for use by the graphical user Interface, which may comprise a number of separate applications operating to send- 
ing control signals to the controllers, for performing various managemerrt functions across the network corresponding 
10 to a control of services, and other management functions on a network-wkie basis at the system level as shown in Rg. 
4 herein. 

[0041 1 Referring to Rg. 6 herein, there is illustrated a logical layout and architecture of the network management base. 
Logically, the system controller, composite controllers arKi component controllers are arranged into application level 
elements which control systems, corrposrtes and components at an application level 600 and Implementation level ele- 

75 ments which control systems, composites and components at an implementatfon level 601 . 

[0042] In this specification, the term "application level elemenf is used to descrit>e an element of a management sys- 
tem relating to a component composite or system in which a furxrtionality of said component, conrposrte or system is 
represented independently of an internal structure of said component, composite or system. 
[0043] An application level element may be capak^le of providing managemerrt signals relating to all aspects of man- 

20 aging a functionality of a component, composite or system independently of internal structure, for example provkling 
signals descnbing a status or performance of a component, composite or system in terms of functionality, independ- 
ently of internal structure or providing control of a component, composite or system independently of internal structure 
of the component, composite or system. 

[0044] In this specif icatbn, the term Implementation level element' used to descrbe an element of a management 
25 system relating to a component composite or system, in which an int^nal structure of said component composite or 
system is represented. 

[0045] An implementation level element may be capable of provkfing management signals relating to all aspects of 
management of a component composite or system, for example provkiing data signals describing status or perform- 
ance of the component composite or system, or providing management control signals for controlling internal physical 

30 resources of the component composite or system. 

[0046] The application level elements and implementation level elements communicate with each other by the send- 
ing arxJ receiving of control and data signals according to a set of mappings 602 t>etween the implementation level and 
the application level. In Rg. 6, graphical user interface 504 can retrieve from both the application level elements and the 
implementation level elements data concerning tiie functionality supported by each component composite or system. 

35 and how tftey are interconnected. A user operating the graphical user interface 504 can perform management opera- 
tions on the network tyy selecting menus, artd options presented on a screen of the graphical user interface, based on 
data descrbing the systems, corrposrtes and components and thar interconnection retrieved from the application level 
elements and the irrplementation level elements. The data describing the systems, composites and components may 
be read by other deuces which may be distributed elsewhere over the network. The other devices may comprise graph- 

40 ical user interfaces of other network controllers which can read the data held by the application and implementation 
level elements on the network controller renrv>tely via the operation, administration and maintenance channels connect- 
ing the nodes, and which may provide various management views 603 of ttie networK eg a 03 interface, ISO or TCP/IP. 
orX.25orATM. 

[0047] A plurality of physical components and composites 604 are managed by the management basa Each compe- 
ls nent operates to perform a specific function or functions in a communk^ations environment For example, an ATM switch 
may comprise a plurality of switch fabric cards which receive cells of data signals and switch them to various destina- 
tions. The indivklual cards are components; the ATM switch is a composita 

[0048] Operation of a physical corrponent or composite is typically effected by focal control mechanisms of the com- 
ponent or composite. The local controls may comprise one or a set of processors, driven by application software items 
50 S Specific to the corrponent or conposite and which may sipport a servfoe, based upon connection and transmission 
of signals over physical links connecting the rxxles. 

[0049] The internal software of components provkjes their functionality. The internal software of physical composites 
provkSes access to the functionality of their erri^edded components. A physfoal component or composite may comprise 
an agent intertece 605 which interfaces t>etween the local control mechanism of the component or composite and its 
55 component or corrposite controller within the management system. The local control mechanisms may conprise ded- 
icated coded instructions which directiy control the component or corrposite and may be proprietary and differ from 
device to device. 

[0060] A physical component or corrposite receives 0AM signals via its corresponding respective agent interface or 
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directly to its local controller. The agent 605 decodes the received OAM signals and implements control of the individual 
conrponent(s) to effect a management operation descrbed by the OAM sigials. For example, as shown in Rg. 6. each 
device nnay be implementing a connection service such as an ATM virtual path. On receipt of OAM signals from a cor- 
responding respective plurality of component or composite controllers, one per device, the devices may co-operate to 
reconfigure the service, eg. by routing the virtual path, creating or releasing connections. 

[0061 ] Refening to Rg. 7 herein there is illustrated an example of a managed componerrt 700. for example a line card, 
switch fat>ric card or a signal processing card or the like together with a component controller 701 for managing the 
conponent. The component 700 comprises a plurality of sut>-components 702-710 each of which carry out a function 
within an overall functionality of the component The component, being modularized in the form of a card which fits into 
an equipment rack having a back plane for communicating with other card components, and a power supply for power- 
ing the card component, can be used in a range of product lines. Conponent controller 701 controls the component. 
The conponent controller is specific to the reusable corrponent. and generates control signals wtiich are used to man- 
age the functionality of the conponent and receives data signals generated by the component which describe a status 
or concfition of the component eg data signals describing cell discard rate, path utilization, or bit error rate. 
[0052] Refening to Rg. 8 herein, there is illustrated a composite device conrprising a plurality of card components 
800-802, each of which is sipported for the purposes of network management by a respective corresponding compo- 
nent controller 803-805 in the network management base. Each component controller 803-805 irrplements manage- 
ment control of its caresponding respective component, and each conponent controller is designed specific to the 
component which it controls. A composite controller 806 controls the composite assembly of components 800-802. The 
composite controller comprises a functk>n controller 807 being an application level element which represents the func- 
tionality of the conposite and an irrplementation level element 808 whk^h conprises the conponent controllers which 
are assembled in a manner which reflects the composition and connectivity of the components in the conposite device. 
The implementation level element is specific to that conposite, and is constructed in a manner whk;h is specific to and 
reflects an internal structure of the conposite. The application level element is constructed in a manner which reflects 
a functionality of the composite independently of an internal structure of the conposite. 

[0053] A conponent controller conprises is lowest form of element of the management base and is not decomposa- 
ble. A conponent controller is treated as a l)lack box" element A conponent controller forms an applicatk>n level ele- 
ment. 

[0054] A composite controller conprises a function controller and one or more component controllers, or a function 
controller and one or more composite controllers or a function controller and a hybrid assembly of conposite controllers 
and component controllers. The function controller comprises an application level element, being a "black box" element, 
and the assemt)ly of conponent controllers and^or composite controllers comprises an implementation level element, 
toeing a "White box'' element in which the internal structure of the assemt}ty of composites and components is repre- 
sented by the structure of the assemt)ly of conposite contrdlers/conponent controllers. 

[0055] A composite controller as a whole may form an inplementation level element of a higher order composite con- 
troller or of a system controller. 

[0056] Conrposite assemblies of conrponents exist at various levels of corrplexity wrtiiin the network. A first composite 
of a higher order may conrprise a plurality of conrponents of lower order. A composite controller within the management 
base comprises a function controller and one or more composite controllers of Iwer order and/or one or more compo- 
nents. 

[0057] A system controller conprises a function controller and an inplementation level element comprising a plurality 
of composite controllers and/or component controllers. A function controller of a system controller conprises a highest 
order of applrcation level element 

[0058] The internal structure of ttie application level element is independent of the architecture and construction of 
the individual components, and represents only functionality of the composite device, not the implementation of that 
functionality. This may have a significant advantage in network management system design, since the conrponents 
800-802 may be collectively or individually replaced by equivalent new components having different internal architec- 
ture and sut>-conponerTts but providing the same overall functionality, and conespondng respective new conponent 
controllers may replace existing conponent controllers 803-805 as appropriate, without needing to replace the whole 
conposite controller or the application level element 807 or other component controllers. Each existing component is 
replaceable by an equivalent new component having equivalent functionality, and its corresponcfing existing component 
controller is replaceable by a new component controller, independerrtly of the other existir>g conponent controllers with- 
out requiring reconfiguration of existing conponent controllers to acconvnodate the new conponent controller. The 
arrangement of Rg. 8 enat>les management of an assembly of conrponents. at a conrposite level as descrit>ed witti ref- 
erence to Fig. 4 herein. 

[0059] Referring to Fig. 9 herein, tiiere is illustrated a second example of a composite device 900 comprising a plu- 
rality of components 901-903 and a control agent 904; and a composite controller 908. Control of the corrposite device 
900 is carried out by composite controller 908. The conrposite controller conprises first and second component con- 
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trollers 905. 906 which are connected together by connecting managed objects 909-912 to form an inrplemefTtation 
le/el element 913, and an application level element 914. Each function type candied out by the conrposite device 900 is 
represented by a corresponding respective managed object 915 in the application lefel element 914. In the case of Fig. 
9. individual first components 901 and 903 are identical to each other and chiplicate each other, and are managed by 
first component controller 905 whereas second component 902 Is managed by second component controller 906. Each 
component controller conprises a plurality of managed otjjects 907. Each managed object relates to a function carried 
out by the component. 

[0060] In general, in a network comprising a plurality of composites, each individual composite controller controls an 
individual composite. Each composite controller is sub-divided into one or a plurality of component controllers. Each 
component controller controls one or wore corresponding components of the same typa Each component controller 
corrprises one or a plurality of managed objects. A corrposite controller comprises a plurality of such managed objects, 
some of which are connected together to form said component controllers, and some of which may interconnect the 
component controllers. Typically a composite controller may corrprise a plurality of component controllers, as well as a 
number of individual managed objects connecting the component controllers within the conrposite controller. The 
arrangement of managed objects within a component controller reflects the separate functions within a componerrt The 
arrangement of component controllers within a composite controller reflects the arrangement of components within a 
composite. 

[0061 1 The application level comprises the plurality of application level elements. Each application level element com- 
prises a plurality of managed objects. Each application level element of the application level is assodated with a func- 
tion provided by at least one conresponding respective component or conposite at the implementation level, and can 
control functionality of a composite associated with a composite controller by sending function signals to the composite 
contrdter which implements control of that composite. Each individual managed object of an application level element 
is connected with at least one corresponding respective managed object of an irrplementation level elemerrt to which 
it sends function control signal A managed object of an irrplementation level element receiving the function control 
signal can signal internally within the composite controller to conpon^ controllers, and the plurality component con- 
trollers comprising the composite controller generate operation, administration and maintenance (OAM) signals which 
are sent across the network to the components conprising the composite, for their management. 
[0062] A relationship between various apparatus and software parts in a network, and the con-esponding controllers 
in the network controller is descrit)ed in table 2 herein. 



Table 2 



Network 


Network Controller 


System 4 — 
Composite 4 — 
Component 4 — 


System ^- ^ Implementation Level 

Controller \. Element 

^ Composite <^ \. 

Controller \ 

Component Application Level 
Controller * Element 



[0063] TTie application level and the irrplementation level have architectures which are structured to reflect both the 
functions and the internal structures of the plurality of composites. The structuring of the application level and imple- 
mentation level are aimed at enabling reuse of composites and their constituent components In a communications net- 
work, without the need for conplete reconfiguration of the application level and implementation level. Conrposite 
controllers and component controllers can be reused across tiie network. 

[0064] Each physical hardware item corrprising a composite conprises a plurality of components arranged in a pre- 
determined order. This predet^rrvned order is reflected in the arrangement cf a plurality of component controllers in the 
implementation level element. The functionality of a corrposite is reflected in the provision of a plurality of managed 
objects in an application level element. 

[0065] A management system can be assembled from assemk)lies of controllers in the same way that a network as a 
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whole can be assembled from a plurality of composites and components. Once a plurality of component controllers 
have been assembled into a composite controller for a corresponding composite, the composite can be reused along 
with the corresponding composite controller. By assembling a plurality of component controllers into a composite con- 
troller corresponding to a legacy network element, encapsulation of management system structure of a legacy equip- 
5 ment is enabled even where new methods of network management are applied. Management functions are 
encapsulated in the application level elements of controllers, and Implementation of those functions as specific to par- 
ticular network elements and components is encapsulated in the implementation level elements of composites, and 
component controllers. 

[0066] In the best mode herein, as a communications n^crk is constructed or oKxlified by addition of new compos- 

10 Ites or components, a management system develops along with the network, as each composite contributes its own 
composite controller(s) to the application level and implementation level respectively. lnteroperat>ility of tiie manage- 
ment system is achieved by ensuring tiiat the assemblage of managed objects within a controller represent every 
aspect of functionality of the device in a modular manner, arKl every significant component is represented by a corre- 
sporxfing component controller. 

IS [0067] In the best nrKxie herein each of the managed objects in the application level comprises a means for storing 
data signals descrbing a function of a composite or a system, the data storage means being readat)le by the graphical 
user interface 504 and other devices, and a means for generating a set of function control signals for sending to the cor- 
responding one or more managed objects in a component controller or implementation level element which actually 
implement control over the corresponding components. 

20 [0068] Referring to Rg. 10 herein, there is illustrated schematically an architecture of a managed object in an appli- 
cation level element. The object comprises a data storage means 1000 containing function data and a signal generator 
1003. The function data is addressat>le and readable by external devices. arKi the g^phical user interlace 504, as illus- 
trated graphically by arrows 1001 , 1002. The signal generator 1003 generates signals, utilizing the function data, and 
optionally, in response to signals received from an external source or from the graphical user interfaca 

25 [0069] Each managed object of a component controller or an implementation level element comprises data storage 
means for storing data descrbing the physical structure and connectivity of a device, including the inter-connection of 
and internal structure of components of the device, and a means for generating operation, administration and mainte- 
nance (0AM) signals for sending to the composite or component for controlling operation of that device, tiie OAM signal 
generating means being responsive to instructions received in the fomi of signals from the graphical user interface 504. 

30 or in the form of function control signals from a managed object of the application level element. 

[0070] Referring to Rg. 1 1 herein, there is shown an internal architecture of a managed object of an implementation 
level element 1 100. The object comprises a data storage means 1 101 storing data describing a composite, a compo- 
nent or sut)-component. and a signal generator 1 102 for generating control signals for controlling a conposite or a com- 
ponent 

35 [0071 ] Referring again to Rg. 6. the graphical user interlace reads data representing the available services supported 
by individual conrposites from the application level, and can read data such as for example performance data from the 
irrplementation level concerning performance of the various network elements and their individual components. The 
grapNcal user interface may send instructions to tiie implementation level for controlling varfoi^ OAM functions for the 
network elements. The implementation level converts these instructions to corresponding OAM control signals to the 

40 individual composites for inrplementing the OAM functions. 

[0072] Refening to Rg. 12 herein, there is illustrated schematically an internal architecture of the network manage- 
ment system described in terms of management levels. The network management system operates to manage com- 
posites arxJ components at a system level, a composite level and a component level. At the composite level, composite 
controllers can be nested within each other. For example, a composite controller 1 200 controlling a composite including 

45 components controlled by first to third conponent controllers 1201-1203 may be nested within a composite controller 
1204 controlling a composite comprising components controlled by first to third conrponent controllers 1201-1203 and 
fourth to sixth component controllers 1205-1207. The composite controlled by a composite controller 1204 may form 
part of a system including other conposites. controlled by another composite controller 1208, the system being control- 
led t>y system controller 1209. The management levels resemt)le a tree structure having branches and leaves. At the 

so leaf level, are component controllers, tiiis being tiie type of control unit which controls the minimum level of replaceable 
product 

[0073] The management system is constructed using specific methods as will now be described. 
[0074] Referring to Rg. 1 3 herein, there is illustrated a general method for constructing a network management sys- 
tem by assembling a plurality of component controllers, composite controllers and system controllers. The method of 
55 construction can be approached via a *1op down" route, wherein the management system is constructed from a consid- 
eration of overall system functionality, or alternatively from a "bottom tp" route wherein construction of the management 
system is approached from a consideration of assembling individual conrponents and composites which comprise the 
communications network. The construction method is flexible and adaptive to accommodate changes to tiie network 
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management system once the system has been designed and constructed, by sut>strtution of composite controllers, 
and component controllers as composites and components are upgraded with newer equipment or as components are 
added or subtracted in order to alter the functionality of systems supported by the communications network. 
[0075] Steps carried out in a 'lop down" construction method may be as follows: firstly, an overall functionality of a 

5 system supported by the network may be represented by creating an application model 1 300 of a system. In the appli- 
cation model, each major function supported by the system is modeled. The application model of the system is used as 
a design plan to aeate an application level element of a system controller. Each function represented in the application 
model of the system is carried out by a composite or a component Each corrposite is controlled by a composite con- 
troller forming part of an implementation level element of the system controller. The implementation level element of the 

10 sy^em controller is constructed as a plurality of application level elements 1302 - 1304 of corresponding respective 
corrposite controllers which are specified in an implementation model desaibing the irrplementation level element 
1301 of the system controller. For the purposes of clarity, an irrplementation model describing an irrplementation level 
element of only one such composite controller is illustrated in Fig. 13. Construction of a plurality of corrponents com- 
prising the composite controller having application level element 1304 is formed according to an inrplementation model 

75 1305 which is used as a dest^ plan for constructing an implementation level element of the corrposite controller. The 
irrplementation level element is cor^ucted according to a implementation nxxJel 1 305 of the corrposite controlier. The 
irrplementation rrxxiel 1305 comprises a plurality of application rrKxJels 1306 - 1309, each of which describes function- 
ality of an individual component comprising the composite. The component controllers are each constructed incfividu- 
ally according to a corresponding respective application model, one per corrponent. The implementation nrxxiels of the 

20 corrponents eg 1310, are constructed as part of the actual components. 

[0076] In the following description there are created assemblies of objects at the application level, each of which 
desaibe an aspect of the functionality of a composite or system and which are directiy manufactured into correspond- 
ing respective application level elements of composite or system controllers. Similarly, there are created interconnected 
assemblies of managed objects at the irrplementation level which describe the structure of a system, composite or 

25 component, and the irrplementation of furxjtionatity wittiin that system, conrposite or component, and which are manu- 
fectured as component controllers and implemenlation level elements of corrposite controllers and system controllers. 
[0077] Referring to Fig. 14 herein, there is illustrated an overview of a general method for constructing a network con- 
troller apparatus for a communications network. 

[0078] In step 1 400. design of the network controller commences with a specification requirement for a new networK 
30 or for an addition to an existing network. The requirement may comprise details such as required bandwidth, required 
call traffic capacity, types of sennce to be carried, types of management information to be accessed, eg quality off serv- 
ice data, cell discard rata In step 1401, the requirements are modeled in terms of managed functions, resulting in an 
application model 1402 descr3>ing the functions to t>e performed by the network. In parallel with creating the application 
rrxxiel 1402, the system structure is decomposed in step 1403 to obtain an implementation rrxxiel 1404. The inrplemen- 
35 tation rrxxiel comprises a specification for the network in terms of individual network elennents and internal components 
of tiiose devices. The application model 1402 and irrplementation model 1404 corrprise a 'lop level" design of tiie net- 
work arxi the network management system. Each of the application model arxi inrplementation nrxxiel are then broken 
down in layers to achieve an application class nrxxiel 1405, a nriapping nrxxiel 1406 and an implementation dass nrxxiel 

1407 which then form the basis for construction of the network mariagement system and construction of the network 
40 controller. The application class model, mapping nrxxiel and inrplementation dass nrxxiel are used as a detailed plan for 

assemt3ling the application level arxi implemerrtation level of the network controller. In the best nrxxie, the managed 
objects may be built into the application l^el elements and inrplementation level elements as code in an object oriented 
programming language such as SmallTalk or 0++, arxi input into the data storage means of the network controller. 
Once established for a particular composite or conponent the assemblies off application level elenrrents. implementation 

45 level elements, and conponent controller are reusable in other network management systems. Classes in the applica- 
tion dass nrxxiel 1405 are constructed to comprise the managed objects off the controllers. 
[0079] The application dass nxxiel 1 405 is determined from the application nxxiel 1 402 as follows: In step 1 408. each 
function in the application nrxxiel 1402 is mapped to an object of the application dass nrxxiel 1405. Where the function- 
ality described in the application nrxxiel 1402 is complex, mapping to objects in step 1408 may comprise a sut>-step 

50 1 409 of nxxieling the connectivity layering , to obtain a layer application nxxiel 1 408 which is mapped to objects in steps 

1408 resulting in the application class nxxid 1405. 

[0080] The inrplementation dass nrxxiel 1407 is determined from the inplenrrentation model 1404 as follows. Each 
structural feature induded in tiie inplementation model 1404 is mapped to an object in step 1401 resulting in the inrple- 
mentation dass nrxxiel 1407. Step 1401 can be sub<iivided into the sub-step of nrxxieling connectivity layering 1402 to 
55 achieve a layered implementation model 1403 which is mapped to objects in steps 1401 resulting in the inrplementation 
class model 1 407. Where there is symmetry in the required functionality as represented by the application dass nrxxiel 
1405. the application class nrxxiel 1405 may be optinnized by folding in step 1404 as a fonm of condsely obtaining the 
application dass model 1405. Similarly, where there is symnrretry in tiie hardware items comprising tfie conrposrtes and 
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components represented by the implementation dass nxxjel 1407. the implementation dass nrxxjel may be folded in 
step 1415 for the purposes of condse construdion. 

[0081] The method described with reference to Fig. 1 4 herein comprises a *1op down" approach for configuring and 
constructing a network management system and communications network to achieve desired functbnality, using mod- 
5 ular components and contrdler structures, each module comprising a managed item, eg of hardware, such as a com- 
posite or component, means for generating a set of control signal instructions, means for storing data signals 
comprising application level elements, and Implementation level elemerrts in the Implementation level and application 
level. 

[0082] Opportunities for reuse of application level elements and implementation level elements and controllers exist 
10 at several levels. 

• Models of management system components, ie application models and implementation models, can be reused as 
the components themselves are reused. 

15 • Aggregations of corrponents arxJ their corresponding component controllers, composite controllers, and system 
controllers can be reuse candidates. 

Individual component controllers can be reused across management systems. 

20 [0083] Referring to Figs. 1 5 to 22 herein there will now be described a first example according to a specific method 
of the present invention for Integrating a sinrple one-zero (1A)) cross-connect composite Into a comnunlcations net- 
work, and incorporating management control in the form of an application level element and an Implementation level 
element into a management system operated by the network controller 402 for managing the conrvnunications network 
The 1 A) cross-connect, its assodated management agent, and a corresponding composite controller for managing the 

25 1A) cross-connect comprise a reusable module in a communications network, the composite controller providing nxxJ- 
ularization of network management functionality within the network controller apparatus. Using the methods described 
herein, a complete network management system residing in the network controller apparatus can be constructed along 
with construction of the network Itself, with the advantage that changes to tiie management system resulting from the 
addition of the 1 A) cross-connect may be limited to the changes introduced by the con-esponding conrposite controller, 

30 and changes to controllers of other network elements can be contained. 

[0084] There will now be described an example of operation of ttie method of Fig. 1 4 with respect to a 1/0 cross-con- 
nect apparatus. For ease of reference, and to fadlHate greater urxjerstanding of the invention, an outline plan of Rg. 14 
herein Is induded adjacent to Figs. 15 to 22. with the relevant steps of the method of Rg. 14 indicated by dark shading. 
In Rg. 1 5 there is illustrated a representation of a 1 A) cross-connect 1 500 which inputs an El stream, comprising up to 

35 32 communk^ations channels, of which 30 may be telephone channels, and outputs the 32 channels via a second El 
stream. The cross-connect 1500 enables rearrangement of the 32 channels of the incoming E1 stream In a Afferent 
order in the outgoing El stream. In Rg. 15. the 1A) cross-conned is represented In a "black box" view as a function, in 
this case the 1/0 cross-connect function. 

[0085] Refen-ing to Rg. 16 herein. In the implementation model 1404 the 1A) cross-connect device Is represented by 
40 its constituent components. The constituent components comprise a de-multiplexer 1601 for receiving the El data 
stream and separating out the plurality of 32 channels; a cross-connect component 1602 for cross-connecting the 32 
input channels onto 32 output channels; a multiplexer 1603 for multiplexing the 32 output channels t>ack into an output 
El data stream; a local controller 1604 for controlling operation of the de-multiplexer 1601 . cross-connect component 
and multiplexer component; and an agent interface 1605 comprising control instructions stored within the 1A) cross- 
45 connect for Interfadng the local controller 1604 with an operatron and management (0AM) channel for receiving man- 
agement Instructions signals from a network controller apparatus. The local controller sets up and renrx>ves DSO cross- 
connections and received 0AM data from traffic nKxIules. 

[0086] In Rg. 1 7. There Is shown a result of modeling connectivity layering in step 1 409 to obtain a layered connection 
model 1 700 of the application nxxlel 1 402. The layered connection model Is an intermediate step between the applica- 

50 tion model 1 402 and the application class nrxxjel 1 405. In some instances, It may be possible to go direcUy to the appli- 
cation dass nxxiel 1405 from the application model 1402 via step 1408 of mapping the application nxxJel to objects. 
[0087] In Fig. 18 herein, there is shown an application dass model corresponding to the application nrxxiel 1402 of 
the 1/0 aoss-connect. The application dass model of the 1A) cross-conned shown in Rg. 18 describes the necessary 
objects required to manage the 1 A) cross-connect, wittiout giving any indication of how tiie 1/0 aoss-connect is adually 

55 structured; the appfication dass nxxiel of the 1/0 cross-conned Is purely functional. By objed it is meant a piece of 
fundionalrty within the management contrdler which reflects some aspect of the managed network, In this case the 1 A) 
cross-conned, for management purposes. In the notation of Rg. 18 herein, a 1/0 cross-connect is composed of many 
(in this case 2) El ports 1 801 , each of which is composed of one E1 connedion termination point 1 802, which Is asso- 



15 



EP0 899 911 A2 

dated with one El trail termination point 1803. which is composed of many DSO connection termination points 1804. 
The derived object structure of the application class model is descrft>ed as a top down decomposition, ie an inverse ori- 
entation. This produces a diagram with the object which represents the systems context at the top. In this case, the 1/0 
cross-connect object 1800 represents the system context for a system comprising a 1/0 cross-connect. 

5 [0088] For example, an El OTP object 1 802 represents the fact that the input El stream has to be terminated. Simi- 
larly, El port object 1801 represents the fact that there is a physical link termination and the El stream is terminated 
within that physical link. Thus, the application class model structure of Fig. 18 represents that for 1A) aoss-connect, in 
order to manage this aoss-connect the management system must be aware that there are physical El ports, which are 
terminatir)g El streams and within the El streams there are a number of DSO connection termination points which are 

10 indlvklual telephone circuits which are t>eing terminated and the indivkiual telephone circuits can be related back to 
each other using a CrossConnect function represented by DSO aoss-connect object 1805. Within the DSO x-connect 
object 1805, there is represented that, for exarrple incoming channel number one can be connected to outgoing chan- 
nel number seventeen, and so for management purposes circuit one entering the 1 A) crossKX)nnect exits on for exam- 
ple circuit seventeen output from the 1/0 aoss-connect. 

15 [0089] Referring to Rg. 19 herein, the implementatk)n model 1404 of the 1/0 cross-connect is broken down in step 
1412 to obtain a layered implementation nxxiel 1900 as shown in Fig. 19. In this case, the layered implementatkxi 
nxxiel comprises three elements, an El -DSO multiplexer 1901 . a DSO aoss-connect 1902, and a second El -DSO mul- 
tiplexer 1903. In Rg. 19, connections to and from Itie function controller have not been nxxleled. 
[0090] In step 141 1 , there is derived an implementation class model as shown in Rg. 20 herein from the layered 

20 implementation nxxiel of Rg. 19. In Rg. 20, the required aoss-connect function has been modeled as a composition, 
and hence a concatenation of: 

• Two DSO cros&<x)nnections 2003, 2004 (within each of two El multiplexers) 

25 • A composite DSO link 2008 between the two El multiplexers, the composite DSO link itself composed of two phys- 
rcal DSO links 2005, 2006 and an internal DSO aoss-connection 2007 within a DSO ^ric 2008. 

[0091 ] The implementatk>n dass model of Rg. 20 has the folkswing characteristrcs: 

30 • The El multiplexer has been nxxieled twice. This mirrors the functions desaibed in the layered application model. 
Both the El multiplexer model copies are kJentical, and therefore represent reusaktle dass behavfor. 

• The ability to loop back" a cross-connectfon to the same physical El port has been accomnrxxiated within the DSO 
fatMic by kx)ping back the DSO cross-connect assodation to the sditary defined DSO connection termination point 

35 (CTP). 

[0092] In Rg. 20, the compositon and connectivity of a physk^al hardware item, (a 1/0 aoss-connect) has been rep- 
resented in terms of its component parts. The complete 1/0 aoss-connect can be constructed out of two El Mux con- 
nect components 2000. 2002. a DSO fabric component 2008 and two DSO links 2005, 1006, each of which connects an 

40 El Mux component to the DSO fabric component. 

[0093] Thus, as shown In Rg. 18 there has been derived an applk:atk)n dass nxxJel and in Fig. 20 there has been 
derived the corresponding implementation dass nrxxJel. According to the specif nrathod desabed herein, the appli- 
cation dass model and the implementation dass model are related to each other as follows: Optionally, in step 1415 
the implementatfon dass model may be folded upon itself. This is possible because of the symmetry within the imple- 

45 mentation dass nxxiel. In the example of Fig. 20, the implementation dass model conprises first and second El -DSO 
multplexers 2000. 2002 respectively, each having the same staicture. The implementation dass model of Fig. 20 may 
be "foMed" ipon itself resulting in the foMed implementation dass model shown in Rg. 21 herein. The implementatfon 
class model of Rg. 20 provides a dear definition of managed objects and assodatfons. The foMed implementation dass 
model of Rg. 21 is more sucdnct. In each of the implementation class models of Rgs. 20 and 21 , the El multiplexer 

50 and DSO fabrfo have been modeled as reusable models which are used to construct a corresponding respective com- 
posite controller. Each composite controller exports a set of management capabilities equivalent to the externally visible 
functionality of the p}hysical component These capabilities are then imported by the composite object "my 1/0 cross- 
connect" and are used to provxie a desired system level behavior. The objects "DSO aoss-connect" and DSO link which 
do not form part of the multiplexer or DSO iabric are associated with "my 1/0 cross-connecT . 

55 [0094] In step 1 41 4 the application dass model of Rg. 1 8 is mapped onto the foMed implementation dass model of 
Rg. 21 such that each object in the application class model is realized by a conresponding object in the implementation 
dass model, as shown in Rg. 22 herein. The implementation dass model contains further information compared to the 
applk;ation model, because the implementation dass nnodel comprises a plurality of objects each of which relate 
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directly to a oorresponding sub-component within the 1A) cross-connect hardware. The application class model pro- 
vides an abstract inrplementation independent view of the managed system, whereas the implementation dass model 
desai>es managed system behavior and structure as it is implemented. In order to perform the specific method 
de8ai>ed herein, both the application model view arvJ the irrplementation nrxxJel view are required. 

5 [0095] When a user requires a specific aoss-connect to t>e estat>lished. a mapping 2200 is followed between the DSO 
aoss-connect object 2005 of the application class nxxJel and the DSO cross-connect object 2009 of the implementation 
class model. The DSO cross-connect in the implementation model is then used via an agent within local controller com- 
ponent of the physical 1 A) cross-connect to setup, monitor and manage the three intemal cross-connections within the 
physical hardware 1 A) cross-connect. Thus, a function element of the application model (the DSO cross-connect object 

10 1805) is realized by a structure element (the DSO cross-connect object 2009 in the inrplementation dass modeQ which 
is used to control via an agent within the local controller component 1604 of the 1/0 physical aoss-connect to setup, 
monitor and manage the three intemal physical cross-connections of the 1 A) aoss-connect 
[0096] In the network management apparatus, in the example of Figs. 15 to 22. the application class model 2201 and 
the implementation dass model are each constructed as the application level element and implementation level ele- 

15 ment respectively Further, the El -DSO multiplexers are represented by component contrdlers and DSO fabric is repre- 
sented by a component contrdler. Both the irrplementation dass nvxJel and the conrponent controllers comprise 
reusable nrxxJules wittiin the network management system. AlttK)ugh the applicatk)n dass model and irrplementation 
dass model in Fig. 22 have been desaifcted as being constructed as controllers in a single network management con- 
troller apparatus, in prindple the controllers can be distributed over different network controller apparatus in a commu- 

20 nications network. 

[0097] Further, the architecture shown in Rg. 22 has builtHn reusability. For example if tiie physk^al hardware item 
comprising the 1/0 aoss-connect is later redesigned or upgraded using different corrponents. the application dass 
model 2201 can be reused, although it may be necessary to nrxxlify the inplementation dass model 2202 to correspond 
with the structure of the redesigned hardware item. For exanple if a new DSO fabric were designed having slightiy dif- 

25 ferent functionality, the DSO component controller may need to be modified to reflect the new physical hardware struc- 
ture of the new cross-connect, and any changes in functionality introduced by the new DSO fabric. Thus, changes 
rec^ired to the management system, on sut}stitution of an upgraded aoss-connect hardware item can be contained in 
the component controller, without needing to nvxlify other conposite or system controllers. 
[0098] Secondly, when constructing a new management system for a new network, a reusable module may corrprise 

30 a physical hardware item, together with its corresponding system controller, composite controller or corrponent control- 
ler. For example in the case of a reusat)le DSO fabric card module, the module may comprise the physical DSO ^ric 
card hardware item itself, and adcfitionally the component controller for managing ttiat physical fabric card. 
[0099] To integrate the system controllers, composite controllers and component controllers, at the system, conposite 
and component levels, the method descrbed with reference to Rg. 14 herein operates recursively as illustrated sche- 

35 maticalty in Rg. 23 herein. /\n inplementation model at the component level corresponds to an application model at the 
component level. M the composite level, an application nrxxJel at the conponerrt level may be contained within an imple- 
mentation nrxxiel at the composite level. That is to say, an application level element controlling functionality at the com- 
posite level, for example one controlling a composite controller, controls component controllers at the component level. 
Similarly, an plication model at the system level may rely on an application model at the conposite level in order to 

40 implement control of network functions at the system level. 

[01 00] As another example of a reusable module, a 1/0 cross-connect composite may comprise the physfoal hardware 
item 1A) aoss-connect itself, comprising two El multiplexer conponents and a DSO fabric card conrponent plus asso- 
dated controller corrponent as well as a composite controller constructed in accordance virith folded implementation 
dass nrKxiel of Fig. 21 and application class model of Rg. 18. 

45 [01 01 ] Thus, when constructing a new communications network from reusat)le nrxxiules. as the physical system itself 
is constructed, the management system can be built-up through the corresponcfing component controllers of the phys- 
ical hardware items as the physfoal network is constructed. This may enable reduced time in produdng network man- 
agement systems when constructing new communications networks, or modifying existing communications networks. 
[01 02] There now fdfows a second exanple according to a specific method of the present invention in which the same 

50 application as described in Rgs. 1 5 to 22, of an El 1 A) cro6s-<x)nnect function is distritxited over an ATM network. 
[0103] In Rg. 24, the El 1A) cross-connect is shown in "black box" application nxxiel view, representing the El 1/0 
aoss-connect function. 

[0104] Physically, the architecture of the El 1A) cross-connect is shown in Rg. 25 as conprising a first El-ATM 
adapter 2500 which converts the El stream into ATM format signals which are then transmitted over an ATM network 
55 2501 in ATM adaptation layer 2 (A/U.-2); and a second El-ATM adapter 2502 for adapting the ATM stream back to an 
El stream. ATM transport is controlled by an ATM manager 2503. The El -1/0 aoss connect is controlled by a system 
manager 2504. 

[0105] Referring to Rg. 26 herein, there is shown an inplementation nrodel of the El 1A) aoss-connect over ATM. 
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An E1 signal is received by E1-DS0 muttiplexer component 2600 which outputs 32 DSO outputs Into a DSO-ATM AAL- 
2 adapter component 2601 . The muttiplexer 2600 and adapter 2601 . together with local controller 2602 comprises an 
E1-ATM adapter 2603. Simitarty, the second El -ATM adapter 2502 is modeled as a DSO-ATM AAL-2 adapter 2604 
feeding 32 DSO channels into an El -DSO muttiplexer 2605 under the control of a second local controller 2606, the 
5 adapter 2604. muttiplexer 2605 and local controlter 2606 comprise a second El -ATM adapter 2607. The El -DSO mul- 
tiplexer model 2600, which is the same as El -DSO multiplexer model 2605 In the implementation model is reusable, and 
is the same as the El -DSO muttiplexer model 1601 or 1603 in Rg. 16 herein. This Is an example of reusable portions 
of the Implementation model. 

[0106] In Rg. 27 herein, there is illustrated a simpltfied architectural view of the 1 A) aoss-connect over ATM. 
10 [0107] In Rg. 28 herein, there Is shown a layered Implementation model of the El 1/0 cross-connect over ATM. The 
layered application nxxJel describes functions of conversion from El to DSO, and conversion of DSO to AAL-2 ATM in 
the E1 -ATM adapters. The ATM network Is nxxieled as a black box. 

[01 08] Referring to Rg. 29 herein, there is Illustrated a corresponding implementation dass model in which each Indi- 
vidual object represents an aspect of functionality of the CTOss-connect The objects can be divided into groups com- 

75 prising designs for application level elements 2900. 2901 , 2902 for the El -ATM adapters and the ATM network. 

[0109] In this example, the ATM network is not nxxJeled in detail, but only up to the first connection termination point 
of an ATM virtual circuit. In order to fully implement the management system corresponding to the network element 
there is a need to distinguish between ATM virtual drcurts and virtual path layers, arxi to model all transport containers, 
for example VC12, TUG*s AU's, if synchronous digital hierarchy (SDH) Is to be used as tiie transport layer. Details of 

20 how to model the virtual containers in SDH, is given in Intemational Telecommunications Union ITU-T Standards 
G.803. The ATM network has been exemplified by modeling a virtual circuitA^irtual path switch, however setting up and 
managing these ATM connections is outside the scope of the cross-connect, as the network ntanagement system inter- 
acts with an ATM manager for this purpose. However, to enable interaction with an ATM network, the ATM and transport 
trails between boxes - the ATM adaptation layer 2 trail is Illustrated. Connections to and from the netwak manager sys- 

25 tem have not been modeled. 

[0110] Referring to Rg. 30 herein there is illustrated an optimized Implementation dass model comprising a plan for 
an implementation level element for controlling the 1/0 aoss-connect The optimized implementation dass model is 
folded upon itself, taking advantage of the symmetry witiiin the implementation dass model. In this case, in Rg. 29 there 
is duplication of the groups of objects 2900, 2901 , and the group of objects 2902 is symmetrical. The optimized (foMed) 

30 imptementation dass model of Rg. 30 comprises an irrplementation level element for the composite controller of tiie 
1/0 cross-connect over the El 1/0 cross-connect over ATM. The required 1/0 cross-connect has been nxxieled as: 

• two DSO-cross-connects which are Intemal to an El -ATM adapter 
35 • an AAL-2 link across the ATM network, which itself consists of: 

• two ATM links (from each El -ATM adapter to the nearest ATM switch) 

• an ATM CTOSS-connect (the end to end connection across the ATM network) 

40 

[0111] In this case the system manager has not been modeled. This requires an ATM connection to each El -ATM 
adapter. The best way to achieve this is to specialize the ATM adaptation layer into two sut>-types: AAL-2 for traffic and 
AAL-5 for control. The conb-oller connection can then be modeled In the same way as for A/VL-2. 
[0112] Refen^ing to Rg. 31 herein, there is illustrated a result of nxxieling the connectivity layering of an El -ATM 
45 adapter to produce a layered implementation nxxlel 3100. The implementation model comprises constituent corrpo- 
nents of a DSO-ATM adapter, an E1 -DSO multiplexer and a controller. In tinis instance, the layered irrplementation model 
for the E1 muttiplexer corrprises an El -DSO adapter model, and DSO-AAL-2 adapter 3002 (the controller has t>een 
omitted for sirrplicity). 

[0113] In Rg. 32 herein there Is illustrated an Implementation dass model of the El-ATM adapter. The implementation 
50 class model corrprises a plurality of objects arranged to reflect the structure of the indivkiual tiardware corrponents of 
the El -ATM adapter. In particular, a group of objects 2000 representing an El multiplexer component has been able to 
be reused in its entirety from the previous implementation dass model of Rg. 20 herein. Much of the ATM aoss-connect 
application rrxxJel has been reused to construct the DSO-AAL-2 adapter model. The required El -ATM AAL-2 cross-con- 
nect function has been constructed from: 

55 

The reused El -DSO cross-connect 

• The DSO aoss-connect within the DSO-AAL-2 adapter 
The link between the two components. 
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[01 1 4] The model does not lend itself to further optimization by folding. 

[0115] In Rg. 33 herein, there is illustrated the application dass model of an El -ATM adapter 2900 on the left hand 
side and the corresponding implementation dass model on the right hand side, the inrplementation dass model com- 
prising groups of objects representing an El multiplexer 2000 and an DSO-ATM AAL-2 adapter 3300. Each object in the 
s application dass nxxlel maps to a corresporxling respective object in the implementation dass nxxlel. The implemen- 
tation dass model comprises additional objects representing detailed structure of the physical El -ATM adapter device. 
The atxjve example demonstrates how a top^jown system decomposition produces a linked set of management ot>ject 
models as shown in general overview in Fig. 34 herein. The linked models developed by the top-down method system 
decompositbn in the ATM 1 A) cross-connect example have some notable features: 

10 

Internal implementation d^ails within the module level models are hidden within these nrxxiules and are not 
exported to higher level systems and application models. 

• The DSO ports within the El multiplexer and the DSO-AAL-2 adapter unit are needed within the El -ATM 
IS adapter system model, but are irrelemnt at the application nxxJel level. 

• The hierarchy of models provkles a set of system ak>stractions at various levels. 

• Gven that the ATM W aoss-connect architecture couM be implemented as a multi-vendor network system, the 
20 models indicate what must be nxxieled within each TMN layer and what must be exported across the network ele- 
ment management layer boundary. 

The composition of the system in terms of a system manager, an ATM network arxl several El-ATM adapter 
units is held at the network manager level: the El -ATM adapter object provides a link^e down to the EM level. 

25 

• The ATM DSO cross-connect AAL-2 link and trail, ATM cross-connect and link, transport and physical link 
object appear on the network management level and are mapped down to the EM level via the corresponding 
connection termination point and trail termination point objects. 

30 [0116] Referring to Figs. 35 to 47 herein there will now be desaibed a third example according to a specific method 
of the present invention. Rg. 35 illustrates an application model "black box" view for the transit exchange. In Rg. 36 
herein, there is illustrated an architecture for a voice-over ATM transit &cchange, the exchange comprises a call 
processing and system management 3600, a first El -ATM adapter 3601 , and a second El -ATM adapter 3602 commu- 
nicating over an ATM network 3603. 

35 [01 1 7] Rg. 37 illustrates an implementation model for the transit exchange. Each major component of the hardware 
items implenr>enting the transit exchange is modeled in the implementation model 3700. For example first El -ATM 
adapter 3601 comprises an E1 protection module 3701. first to fourth El -DSO multiplexers 3702-3705 and a DSO-ATM 
adapter 3713. The call processing and system management 3600 is represented as main and standby MTP-3 proces- 
sors 3706. 3707; main and stancfoy ISUP/call controls, 3708. 3709; first and second MTP-2 frame processors 3710. 

40 3711 and an ATM system manager 3712, and El -ATM adapter 3602 is represented similarly as the first El -ATM 
adapter 3601 . The voice-over ATM transit exchange of Rg. 37 as illustrated exhibits some additional management rrxxJ- 
eling aspects which exemplify a carrier strength application. In the application model, managed objects for SS7 signal- 
ing and tor the transit switching function are modeled. In the architecture model, management of the ATM AAL2 pipes 
between El -ATM adapter units, known as virtual trunk groups (VTQs) are modeled. In the implementation model, a 

45 model of processor plus software load; 1+1 protection of call processing modules; 1:M protectk>n of the El trunks, as 
implemented t>y the El protection module; and internal connections between call control, frame processor (^ATP-2) and 
signaling links are nrKXleled. 

[01 1 8] Referring to Fig. 38 herein, the application model is a "black box" view of a simple transit exchange with pro- 
tected E-1 trunks (there is no signal transfer point capability and no advanced features), where attached DSO drcuits 

so carry either traffic or signaling links. Traffk; channels are aggregated into voice routes whk^h aggregate the traff k; carried 
between adjacent exchanges. Signaling links are aggregated into signaling link sets, which carry signaling information 
between adjacent exchanges. Withiin the exchange, signaling information terminates at a signaling point MTP-3 pro- 
vides reliable transport of messages between signaling points. ISUP is a user part which interprets signaling messages 
arxi sets up and tears down calls. Rg. 39 herein illustrates an application dass model of the transit exchange of Figs. 

55 35 and 38. where each function carried out by the transit exchange is represented by a corresponding function element. 
[01 1 9] Referring to Rg. 40 herein, specific features of the ATM transit exchange architecture which must be modeled 
in the implementatbn model are: 
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• call processing and system management (initially as a black box functional entity, to be decomposed into its con- 
stituent parts as modeling progresses). 

• The El -ATM adapter arxj its ability to provide protection of El trunks. 

5 

Cross-ATM virtual drcuits used for: 

• control pattis 

• signaling paths (tc/from call processing) 
10 • traffic 

• virtual trunk groups (VTGs) 

[0120] There is shown in Rg. 40 herein a folded implementation class nrxxiel for the transit exchange in which first 
and second El -ATM Raptors are nxxieled by a single assembly of objects, and the call processing and system man- 

15 agement are modeled as an assembly of objects. 

[0121] In Fig. 41 there is illustrated the application class model and the Implementation dass nrxxiel in which each 
class in the application dass nrxxiel is imp)lemented by a con-esponding dass of the implementation dass nxxlel in this 
case, a small portion of the application dass model and the corresporxiing portion of the irrplementation class nrxxlel 
are shown. Each cross exchange traffic connection has been modeled as two DSO-ATM adaptation cross-connections 

20 plus a cross-ATM VTQ link. Each terminating signaling link has been nxxJeled as a DSO-ATM adaptation aoss-connec- 
tion plus a aoss-ATM signaling VC between a DSO-ATM adaptation unit and a call processing entity. 
[0122] Refening to Figs. 42 and 43 herein there is illustrated how a call processing feature of the ATM transit 
exchange is nxxieled. A template inplementation nrxxiel 4200 for a processor module is used to construd a s^ of 
structure elements representing an MTP-3 processor module 4301, and an ISUP/CC processor module 4302 in an 

25 implementation dass model of the processor nxxlule. The ATM transit exchange call processing is spirt aaoss two 
processors, one with MTP-software and one with ISUP and call contrd software. The object model for the generic proc- 
essa module 4200 is a framework which is spedalized and extended for specific processor load typ>es. The ATM VC 
CTP has in each case been further spedalized to nrxxJel the varkHJS connections which have terminations in them at 
the software level. Generic processors with non-ATM ports may be similarly modeled. 

30 [0123] Referring to Rg. 44, there is illustrated how each processor in the ATM transit exchange implementation nrxxlel 
has been duplicated to provide resilience against nrK>st cases of software or processor failura The nrxxlel in Fig. 44 pre- 
sumes tfiat sparing has been realized on a per processor basis (finer ^in sparing is possible on a per application basis 
and woukJ be modeled in simitar fashion). 

[0124] A resilient processor nxxJule is constructed from two non-resilient processor nrxxJules which have been con- 
35 figured with a sparing capability. This capability is implemented by: 

• a virtual channel between a pair of processors whk;h provides a heartt>eat between the processors and check- 
points in between spared applications on the processors. 

40 • additional software within the infrastructure to control sparing. 

[01 25] The system manager can provision sparing or can force switch over between processor modules by operating 
upon the resilient processor module object. 

[01 26] Referring to Rg. 45 there is illustrated an application nrxxlel and in Rg. 46 there is illustrated an irrplementation 
45 nxxiel of El trunk protection. The El trunk protection nrxxi^ witiiin the E1-ATM adapter unit provides 1 :M protectk>n of 
El information. Time slot 0 is used to control protection. To support continued operation in the case that the spare El 
trunk fails, the signaling information is duplicated in one of the main El trunks. The spare El trunk is able to substitute 
for any of the main El trunks in case of failura The block diagram in Fig. 46 descrit>es an internal structure of an E1 
protection nrxxlule. 

50 [0127] In Rg. 47 herein, the El protection module implementation model is converted into an implementation dass 
nrxxjel which specifies that a protection contrd information in time slot 0 is part of an El trail. The El payload, ie the El 
data stream is the part tfiat is actually aoss connected witfiin the nrxxlule. 

[0128] In Rg. 48 herein, there are illustrated how to depict internal control connections needed to reach the MTP-d 
application via a signaling link. Other internal control and management connections can be nxxieled in a similar way 
55 For simplicity, TTP objects have been omitted in Rg. 48. 

[01 29] In Rg. 49, there is illustrated an application dass nrxxlel and an implementation dass nrxxlel comprising a plu- 
rality of dasses which in practice are realized as a corresponding set of application level elements and implementation 
level elements in a network contrdler. the mappings between the application class model and ttie implementation dass 
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model shown by dark arrows are implemented in practice as embedded signaling between the application le^el ele- 
ments and implementation level elements in the network controller, hlaving modeled the intemal connections required 
to support a signaling link, this can now be mapped back onto the application dass model for the ATM transit exchange. 
[01 30] Using the above method of constructing a management system, there may be enabled more efficient construc- 
5 tion of the management system in recftjced time through the following features which are inherent in the atx]ve 
desabed methods: 

Separation of application nxxJels describing functionality of network elements from implementation models 
desait>ing design of composite controllers for implementing control of tfK>se composites, and the explicit mappings 
10 between the implementation models and application nxxJels, enables implementatiors, for example Implementa- 
tions of specific equipment configurations, or whatever the implementation model represents, to be reused aaoss 
different applications. Conversely, as an application model evolves, different component models may be substituted 
in the implementation model. 

IS • When developing new hardware equipment for composites, tiie equipment may be constructed in terms of compo- 
nents which have a conrunon architecture and common framework for instantiating a functbnality. Specific function- 
ality may be added onto this common equipment for performing specific purposes. 

[0131] If, in the management system the comnwn functionality of ec^ipment is modeled separately from the specific 
20 functionality, then as a common equipmertt item Is reused throughout the network, the implementation nxxJel corre- 
sponding to the common equipment can be reused throughout the management system, or in other management sys- 
tems. Management of the common aspects of tiie equ9>ment can be reused from management system to management 
system. An implementation model may comprise a plurality of objects describing a common part of the equipment, and 
parts of the equipment which are specifk; to a particular application can be modeled by additional objects in the imple- 
25 mentation dass nxxlel. or as a sut)-dass of an existing ot>ject in the implementation model which customizes the gen- 
eral equipment for a specific purpose. For example referring to Fig. 50 herein there is illustrated an application dass 
model 5001 for an item of conrunon equipment, adapted for a specific function, together with its corresponding imple- 
mentation model 5002. The common equipment item is customized for digital signal processing. The implementation 
model 5002 corrprises an implementation nxxiel 5003 for the common equipment together with an implementation 
30 nKxIel 5004 specific to the digital signal processing. The composite of the common equipment implementation model 
5003 and the digital signal processing model 5004 customizes the equipment for the digital signal processing function. 
An application level element arising from tiie application class model 5001 maps across directly to a corresponding 
implementatkxi level element in the implementation dass nxxiel 5002. Thus, functionality of the custonvzed equipment 
is described in the network management system an application level element constructed in accordance with appli- 
es cation dass nrxxlel whilst the implementation and operation of the customized equipment is represented in the network 
management system by an implementation level element constructed according to the implementation dass model, 
which itself corrprises an implementation dass sut>-nrKxJel relating to the part of the equipment which is common. 
[01 32] To customize the comnrK>n equipment for a different functk>n, for example ATM access, the customized equip- 
ment is represented in the management system by an irrplementation level element constructed according to an imple- 
40 mentation class model comprising the common equpment implementation dass sut>-model and a further 
implementation dass sub-model constructed of specific component controllers and by an application level element con- 
structed in accordance with an application dass nxxiel desaibing the ATM access function. In the network manage- 
ment system, the application level element controls the irrplementation level element in accordemce with mappings 
between the dasses of the application dass model and implementation class model respectively. 
45 [0133] The common eqiopment is application independent and can be customized for specific functionality, and tiie 
corrponent controller in the network management system corresponding to the common equipment is also application 
independent and can be customized by addition of other component controllers to give application specific control of 
the equipment 

50 • New or enhanced functionality can be applied across a wide variety of models: Although specific application dass 
models and inplementation dass models are dedicated to specific functions arxi specific composites, with some 
reuse of common equipment emt>edded, tfiere are some management functions which apply to a majority of the 
corrposites and their constituent components, such as for example fault management, configuration management 
and performance management because these types of functions are common regardless of what type of equip- 

55 ment or applications are induded in the network. The same structures of objects can be applied to application level 
elements controlling furx;tions of a wide variety of equipment. For example the generic aspect of configuring a man- 
aged object can be applied to a DSO port a DSO connection termination point, and so. Thus, there is an advantage 
in that whenever a new item of hardware equipment of a composite is built, which needs to be managed, because 
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the equipment in general will be constructed from a kncwn pool of components, the component controllers repre- 
senting items such as termination points, ports, cross-connects and links will recur. Each time one of these items 
appears, the corresponding portions of the management system can be reused, without the need to manufacture 
new component controllers. Further, where a hardware component is modified, the conresponding application level 
5 element need not t>e altered. Only a new component controller needs to be created for the new component 

• New or enhanced functionality has value across all models. Thus, if a management functionality is improved, those 
improvements can be applied across all composites and components. Thus, if for example management function- 
ality is enhanced to provide enhanced alarm correlation, that enhanced alarm correlation can be applied to all oom- 

10 posites elements and components of the network. Thus, management functions can be incrementally Improved 
without the need for complete management system restructuring, but rather only by incremental management sys- 
tem restructuring. Inaemental improvements to the network management system representing improvements in 
management functionality can be made independently of incremental improvements to the management system 
reflecting improvements in the composite and conrponent equipments. 

15 

• The management system can be viewed from several different views due to its separation of constructkKi into the 
plurality of application level, implementation level, system controllers, composite controllers and component con- 
trollers. For example, the internal structure of the network controller is not locked into any one particular view, and 
views can be added inaementally. For example cfifferent customers may require different types of interface to the 

, 20 management system for example different machine-machine interlaces. Using the present methods herein each 
interface can be constructed incrementally. It is not necessary to reconsider the whole management system when 
applying a new interface arxl cfianges to the management system can be constrained. 

• Th3 same views may be offered over different underlying transport protocols. The graphical user interface view is 
25 separated from the application model and implementation models within the management system, and the graph- 

cal user interface views may be offered over different transport protocols eg X.25. ATM. 

[0134] Refening to Rg. 51 herein, there is illustrated steps for constructing a network management system t>ased on 
a combined object model as obtained with reference to Rgs. 14 to 50 herein. The steps illustrated in Rg. 51 are shown 

30 in a sequence which may be followed where a plurality of composites and components for a communications network 
have already been selected, and a management system for that network is to be constructed. In step 5100, a set of 
functionality requirements which are to t>e managed are modeled in terms of l)lack box" functk>ns as descrit>ed here- 
inbefore. A plurality of black box functions are modeled interconnected, to obtain a functionality structure comprising an 
application model as hereinbefore descrit)ed. In step 5101, the management system functionality is decomposed into 

35 an implementation nxxlel, in which each composite and component of the network is descrit>ed in terms of its compo- 
nent structure to form an implementation model. Connectivity between Islack box" models of components and compos- 
ites is included in the implemen1atk>n model. In general, replaceable and reusable components are modeled as t)la(^ 
boxes". In step 5102, the structure comprising the application model is decomposed into a plurality of function objects, 
each representing furv;tions to be managed, to obtain an application class model as hereinbefore descritsed. In step 

40 51 03. ttie component structures arxi composite structures of the implementation model are decomposed into a plurality 
of interconnected structure objects arxj assemblies of structure objects representing components arxi composites, to 
obtain an implementation class model as hereinbefore desaibed. The implementation dass model may comprise a 
folded implementation class model for optimizatron of the network management system. In step 5104, each function 
object of the application class model is connected to a corresponding structure object of the implementation dass 

45 model by a mapping, to obtain a combined dass nxxJel as hereinbefore described. The combined dass model is then 
used as a plan for constructing the management system in terms of application level elements, implementation level 
elements, system controllers, composite controllers, and component controllers. In step 5105. each function object and 
each structure object of the combined object model are constructed as a corresponding application level element or 
implementation level element as appropriate. 

50 [01 35] Refening to Rg. 52 herein, there is explained a method of constructing objects of the combined object model 
as a set of system controllers, composite controllers arxi component controllers. In step 5201 , objects are assembled 
to form individual component controllers according to the layout of objects given in the combined object model. The 
component controllers are constructed by implementing ttie objects in an object oriented progranvning language which 
is used to control a processor and communications interface ports to send ttie appropriate 0AM signals to the compo- 

55 nent itself, for managing ttiat component. In step 5202, the component controllers are aggregated into assemblies of 
component oorrtrollers linked together by further objects to form implementation level elements of corrposite controllers 
according to the plan specified in the combined object model. In step 5203. a plurality of objects representing function 
only of a composite are assefTt)led to form a plurality of application level elements of a conresponding plurality of com- 
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posite controllers according to the plan defried by the connbtned object nrxxie). In step 5204. Ibr each composite con- 
troller, the application level element and implementation level element are connected so as to communicate with each 
other, the connections being constructed in the object oriented programming language, in accordance with a set of 
mappings t>etween objects of the application level element arxi objects of the implementation level element of the com- 

5 posrte controller. In step 5205, a plurality of objects desa&ing functionality of a system are assembled into an applica- 
tion level elemerrt of a system controller, according to the plan specified in the combined object model. In step 5206. a 
plurality of implementation level elements of corrposite controllers, arxl a plurality of component controllers nested 
within the implementation level elements are asserTt)led in accordance with a plan given tyy the oonrttxned object model 
to obtain an implementation level element of a system controller. In step 5207. objects describing functionality in the 

10 application level element of the system controller are connected to the internal objects of the inrplementation level ele- 
ments, composite controllers arxi component controllers by means of mappings specified in the combined object model 
in order to aeate a complete system controller. 

[0136] Refenring to Rg. 53 herein, there is described another exanrple of steps for constructing a network manage- 
ment system using a library of reusable replaceable components and libraries of function controllers and component 

75 controllers as hereinbefore descrflsed. In step 5300 a requirement for a modification of a functionality of a communica- 
tions network is estat3lished. In step 5301 . appropriate components are selected in order to fulfill the functional require- 
ments. In step 5302. component models connprising individual implementation nrxxfels for individual components as 
hereint)efore described, which correspond to corrponents selected from component Ibrary 5016 are composed and 
aggregated in step 5303 to form an aggregate implementation model 5304 reflecting the new functionality requirement 

20 set out in step 5300. The aggregate implementation nrxxJel obtained in step 5304 may be at)stracted in step 5305, for 
example by folding of the implementation model as hereinbefore desaibed. When new network elements are aeated, 
through the composition aggregation of components, in steps 5303 and 5304, the implementation dass rrxxlels 
obtained through th^ process may be added to the component library 5306 for future use. The aggregate implementa- 
tion nrxxlel 5304 may be arrived at iteratively by assenrtbly and conrposition of components from the component lOsrary. 

25 Physical construction of new network elements comprising a plurality of existing corrponents may involve addition of 
sutHXjmponents to link the components. Each sub-corrponent may t>e controlled by a new sut>-conrponent controller. 
The new sub-component controllers which connect the component controllers need to be designed and constructed. 
However, ttie corrponents and corrponent controllers which were taken from the conponent library 5306 need not be 
redesigned, but are assembled to each other as rrxxlular units wherein assembly of a set of hardware corrponents is 

30 reflected in the management system by assembly of a set of corresponding corrponent controllers. 
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AAL 


ATM Adaptation Layer 


ATl^ 


AsyrK;hronous Transfer Mode 


CCITT 


Comit6 Consultatif International T^l^graphique et T^6phonique (part of ITU). 


CMIP 


Conrunon Managenrrent Information Protocol 


CI^ISE 


Common Management Information Sennce Elements 


CTP 


Connection Termination Point 


DSP 


Digital Signal Processor 


IBM 


International Business Machines 


IP 


Internet Protocol 


ISDN 


Integrated Services Digital Network 


ISUP 


ISDN Services User Part (of SS7) 


ITU-T 


International Telecommunications Union 


MIB 


Management Information Base 


MTP 


Message Transfer Part (of SS7) 


NC 


Network Controller 


NE 


Network Element 


NMF 


Network Management l=brum 


0AM 


Operation, Administration and Maintenance 


OSl 


Open System Interconnect 


SNMP 


Simple Network Management Protocol 


SS7 


Signalling System No 7 


TCP 


Transmission Control Protocol 


TTP 


Trail Termination Poirt 
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VC Virtual Circuit 
VTQ Virtual Trunk Group 

Claln^ 

5 

1 . A method of constructing a management base of a communications networK said communications network com- 
prising: 

a plurality of components, component comprising a unit of manufacture providing a functionality within 
10 said network, and which is capable of being managed Individually as a discrete entity; 

seiid plurality of components arranged into a plurality of assemblies cf conrponents, each said assembly 
arranged to co-operate with other said assemblies, and each said assembly capable of being managed as a 
whole; 

said method characterized by comprising the steps of: 
IS representing an cverall functionality of said network by an application model (1402), in which each said func- 

tion of said network is nrKXIeled independently of its inplementation within said network; 

decomposing said application model into an implementatk>n model (1404), in which every function represented 

by said application model is represented in said implementation model; 

representing said application nxxJel as a first plurality of objects (1408); 
20 representing said implementation nxxJel as a second plurality of olpjects (1411); 

connecting said first plurality of objects with said second plurality of objects to obtain a combined object nxxJel; 

and 

corstructing said management t>ase in accordance with said combined object model. 

25 2. The method as claimed in claim 1 . wherein said step of representing said application model as a first plurality of 
objects conprises: 

nfKxieling a connectivity layering (1409) between individual modeled functions witiiin said application model. 

30 3. The metfxxi as claimed in daim 1 of 2, wherein said step of representing said inplementation model as a second 
plurality of objects comprises: 

modeling connectivities (1412) between assemblies of components at a first layer and assemblies cf compo- 
nents at a second layer. 

35 

4. TTie method as claimed in daim 1 , 2 or 3, comprising the step of optimizing said application class model by: 

identifying symmetrical portions of said application dass model; and 
fbkling said symmetrical portions to obtain a folded application class model. 

40 

5. The method as daimed in any one of the preceding daims, conrprising the steps of optimizing said implementation 
dass model by: 

identifying symmetrical portions of said inplementation dass nrvxJel; and 
45 folding said symmetrical portions of said inplementation dass model to obtain a folded implementation dass 

nxxlel. 

6. The method as daimed in any one of the preceding claims, wherein individual portions of said implementation 
nxxlel representing duplicated conrponents or assemblies of components are re-used wittiin said inplementation 

50 model. 

7. The method as daimed in any one of tiie precedng daims, where in indvidual elements of said application nrxxJel 
representing a duplicated said component, or a duplicated said assent of components is re-used within said 
application model. 

55 
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of application to corresponding 
plurality of sub-component controllers of 
implementation model 



Fig. 52 
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5204 



Assemble objects to form 
application level elements of system 
controllers, according to plan given 

by combined object model 



Assemble objects, implementation level 
elements of composite controllers and 
plurality of component controllers in 
accordance with plan given by combined 
object model to obtain implementation 
level elements of system controllers 



Assemble application level elements and 
implementation level elements of system 
controllers by connecting objects of application 
level elements of system controllers with 
objects in implementation 
level elements of system controllers 



Fig. 52 
(continued) 
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